Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple bug fixes to run parsec benchmark #189

Merged
merged 5 commits into from
Oct 17, 2024
Merged

Conversation

notlqr
Copy link
Contributor

@notlqr notlqr commented Oct 16, 2024

No description provided.

@notlqr notlqr force-pushed the debug-parsec-2024-10-16 branch 2 times, most recently from edcef2a to ee976b4 Compare October 16, 2024 07:28
@shinezyy
Copy link
Contributor

Clean solution for TLB priv level !

Change-Id: Ied973af5919b83c9fb88b66763958bbde11981d8
Change-Id: I986028fc43759dfa5d9c486687e971e931a730cb
Change-Id: Icfa64a99b9af5cb8fba58b45ce6712df46f2c012
No need to signal from L1D now

Change-Id: I20db1f49e254adb518a8150b6c091358d21d2310
Previously, `fault->invoke()` updates priv immediately, TLB also
translate using new priv. There still might be some instructions going
to IEW at the moment. This is because interrupt traps when ROB is empty,
but somehow these instructions are not in ROB yet.
Such data race on processor PRIV causes mem accesses to bypass addr
translation, thereby accessing a non-existent paddr, which would not be
filtered out because GEM5 thinks they are PIO addrs.
This fix makes TLB use old privilege mode until squashing signal is
sent to IEW.

Change-Id: I016e81069d090269afe4e40f14396cd9163f9ccd
@@ -835,7 +835,7 @@ Fetch::finishTranslation(const Fault &fault, const RequestPtr &mem_req)
// If we have, just wait around for commit to squash something and put
// us on the right track
if (!cpu->system->isMemAddr(mem_req->getPaddr())) {
warn("Address %#x is outside of physical memory, stopping fetch, %lu\n",
DPRINTF(Fetch, "Address %#x is outside of physical memory, stopping fetch, %lu\n",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use "warn" can help us find the fetch stuck easier

Copy link
Contributor

@shinezyy shinezyy Oct 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use "warn" can help us find the fetch stuck easier

But if on the speculative path, might it be too verbose?

@notlqr Did you observe a too verbose print here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some benchmarks produce too much warns here

@notlqr notlqr merged commit 04dd386 into xs-dev Oct 17, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants